In computer science, a virtual machine (VM) is a portion of software that, when executed on appropriate hardware, creates an environment allowing the virtualization of an actual physical computer system. Each VM may function as a self-contained platform, running its own operating system (OS) and software applications (processes). A host machine (e.g., computer or server) is typically enabled to simultaneously run multiple VMs, where each VM may be used by a local or remote client.
Within the host machine, a hypervisor manages allocation and virtualization of computer resources for the VMs and performs context switching, as may be necessary, to cycle between various VMs. The hypervisor allocates a certain amount of the host's resources to each of the VMs. Each VM is then able to use the allocated resources to execute applications, including operating systems known as guest operating systems. The hypervisor virtualizes the underlying hardware of the host machine or emulates hardware devices, making the use of the VM transparent to the guest operating system or the remote client that uses the VM.
Frequently, the hypervisor itself does not have an external connection to the outside network. Although users and administrators want the VMs to be connected to an external network, the hypervisor is not hooked into external public networking because it is meant to be isolated from the VM. This isolation of the hypervisor is desired for security purposes. The host machine has a network connection for the hypervisor to the internal network of the organization, but not to the outside world.
A problem encountered by the lack of connection to the external network by the hypervisor is updating the hypervisor software itself. Previous solutions ran a local update to cause the hypervisor to connect to a local update server within the internal network of the organization. This local update server would have access to the external networking in order to obtain updates to stream to the hypervisor. Unfortunately, this solution is problematic because it relies on an external additional server and typically these update servers cost additional licensing fees and other maintenance and complexity costs.
Another previous solution was to have a system administrator manually re-install a hypervisor when an update is required. Such a manual re-install is typically accomplished using a CD-ROM or USB disks. Generally, this solution is applied to ROM (read-only memory) hypervisors. ROM hypervisors operate so that every time they are updated, all software of the hypervisor is re-installed and all previous versions of the hypervisor are erased. This requires a re-boot of the hypervisor as part of upgrade process. The problem with this solution is that it is manual (i.e., time consuming) and demands a re-boot of hypervisor. This results in the disadvantage of any VMs managed by that hypervisor being unable to run in this period of time that the hypervisor is re-booting.
As a result, a mechanism to provide for downloading hypervisor updates without requiring additional hardware or manual programming would be beneficial.